home *** CD-ROM | disk | FTP | other *** search
- Path: keats.ugrad.cs.ubc.ca!not-for-mail
- From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
- Newsgroups: comp.lang.c
- Subject: Re: Memory. How is it organised?
- Date: 7 Mar 1996 14:56:41 -0800
- Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
- Message-ID: <4hnpj9INN18h@keats.ugrad.cs.ubc.ca>
- References: <4hf5gs$1f7@news.mistral.co.uk> <4hf9j8INNko4@keats.ugrad.cs.ubc.ca> <4hipt4$48t@news.mistral.co.uk>
- NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
-
- In article <4hipt4$48t@news.mistral.co.uk>,
- Mike Barnard <mikebarnard@mistral.co.uk> wrote:
- >Thanks for taking the time to write such a full reply. I've
- >read over it briefly and will study it a bit closer during
- >the evening. Why isn't such information included in newbie
- >tutorials...
-
- Because such information would only help assembly language hackers like me
- misunderstand the abstract nature of the language, and cause them to repent in
- a UseNet newsgroup years later.
-
- A C environment can _interpret_ your program, avoiding a translation to machine
- code altogether. Function activation records don't have to be stack frames, for
- instance. They can exist as dynamically allocated objects inside an
- interpreter. Pointers don't have to be machine addresses; they can be abstract
- identifiers that allow an interpreter to reference objects when it is emulating
- the program. Do you see what I mean?
-
- A knowledge of the internal organization of a C program can be helpful to more
- advanced programmers, as long as they remember at all times that the language
- has an abstract definition.
-
- The language just happens to be conceived in such a way that the structures it
- defines map naturally and efficiently onto digital computers that have a
- certain kind of architecture.
- --
-
-